ECN (Explicit Congestion Notification) is known as a congestion control technique in an IP (Internet Protocol) network. ECN is defined by IETF (Internet Engineering Task Force) RFC 3168, “The Addition of Explicit Congestion Notification (ECN) to IP”. ECN enables notification of congestion in an IP network on an end-to-end basis. ECN can be effectively used when two end nodes (hosts) both support ECN and rooters in an IP network also support ECN.
ECN uses two lower bits of a TOS (Type of Service) field having one octet (8 bits) defined in an IP header. These two bits are referred to as ECN fields or ECN bits, and indicate one of the four following codepoints:                00: Not ECN-Capable Transport (Not-ECT);        10: ECN Capable Transport (ECT(0));        01: ECN Capable Transport (ECT(1)); and        11: Congestion Experienced (CE).where The Not-ECT codepoint “00” indicates that a sender host does not support ECN or does not use ECN; two ECN Capable Transport (ECT) codepoints “10” and “01” indicate that sender and destination end nodes both support ECN and an IP packet, is using ECN; and the Congestion Experienced (CE) codepoint “11” is set by a rooter to notify congestion in the network to end nodes.        
When experiencing congestion, a rooter rewrites an ECN field of an IP packet to which the ECT (0) or ECT (1) codepoint has been set, i.e., an ECN-enabled IP packet, to the CE codepoint (“11”). When the CE codepoint has been set to an IP packet, routers positioned in a downstream of a packet flow do not change the ECN field of this IP packet. When receiving an IP packet to which the CE codepoint has been set, a destination end node handles the congestion notification in an upper layer protocol (e.g., TCP (Transport Layer Protocol) or RTP (Real-time Transport Protocol)). The destination end node which has received the CB codepoint notifies the sender end node of the congestion by, for example, setting an ECE (ECN-Echo) flag of a TCP header or using a RTP message. The sender end node, which has received the notification, for example, reduces a TCP transmission window size or a codec rate to reduce a transmission data rate.
Further, IETF RFC 3168, IETF RFC 4301 “Security Architecture for the Internet Protocol”, RFC 6040 “Tunneling of Explicit Congestion Notification” and the like disclose an operation of a tunnel end point when ECN-enabled IP packets are encapsulated. For example, IETF RFC 4301, which is related to IPsec, discloses operations of a tunnel ingress end point and egress end point as follows. The tunnel ingress end point copies an ECN field of a header of an arriving IP packet (i.e., an inner IP header) to an ECN field of an outer header of the tunnel. Meanwhile, when a CE field of an inner IP header indicates the ECT(0) or ECT(1) codepoint; and the CE codepoint is marked, in. an outer header, the tunnel egress end point copies an ECN field of the outer header to the inner header, in other cases, the tunnel egress end point does not change the ECN field of the inner IP header.
The above-described ECN is also applied to a 3GPP (Third Generation Partnership Project) mobile communication network. More specifically, section 11.6 of 3GPP TS 36.300 defines congestion notification on a radio link between a base station (eNB: evolved NodeB) and a mobile terminal (UE: User Equipment). Further, 3GPP TS 26.114 defines use of ECN in MTSI (Multimedia Telephony Service for IP Multimedia Subsystem), i.e., a speech codec, and, more particularly, defines a behavior of a mobile terminal when the mobile terminal receives the CE codepoint. According to 3GPP TS 36.300, in order to increase capacity (e.g., in terms of number of accepted VoIP (Voice over IP) calls) or to improve coverage, a base station sets the CE codepoint to PDCP SDUs (Packet Data Convergence Protocol Service Data Unit), i.e., user packets, which is indicating the ECT(0) or ECT(1) codepoint.